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Requirements for Very Fast Setup of GMPLS Label Switched Paths (LSPs) 
Abstract 


Establishment and control of Label Switch Paths (LSPs) have become 
mainstream tools of commercial and government network providers. One 
of the elements of further evolving such networks is scaling their 
performance in terms of LSP bandwidth and traffic loads, LSP 
intensity (e.g., rate of LSP creation, deletion, and modification), 
LSP set up delay, quality-of-service differentiation, and different 
levels of resilience. 


The goal of this document is to present target scaling objectives and 
the related protocol requirements for Generalized Multi-Protocol 
Label Switching (GMPLS). 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7709. 
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1. Introduction 


Generalized Multi-Protocol Label Switching (GMPLS) [RFC3471] 

[RFC3945] includes an architecture and a set of control-plane 
protocols that can be used to operate data networks ranging from 
packet-switch-capable networks, through those networks that use Time 
Division Multiplexing, to WDM networks. The Path Computation Element 
(PCE) architecture [RFC4655] defines functional components that can 
be used to compute and suggest appropriate paths in connection- 
oriented traffic-engineered networks. Additional wavelength switched 
optical networks (WSON) considerations were defined in [RFC6163]. 


This document refers to the same general framework and technologies, 
but it adds requirements related to expediting LSP setup under heavy 
connection churn scenarios, while achieving low blocking under an 
overall distributed control plane. This document focuses on a 
specific problem space -- high-capacity and highly dynamic connection 
request scenarios -- that may require clarification and or extensions 
to current GMPLS protocols and procedures. In particular, the 
purpose of this document is to address the potential need for 
protocols and procedures that enable expediting the setup of LSPs in 
high-churn scenarios. Both single-domain and multi-domain network 
scenarios are considered. 


This document focuses on the following two topics: 1) the driving 
applications and main characteristics and requirements of this 
problem space, and 2) the key requirements that may be novel with 
respect to current GMPLS protocols. 


This document presents the objectives and related requirements for 
GMPLS to provide the control for networks operating with such 
performance requirements. While specific deployment scenarios are 
considered part of the presentation of objectives, the stated 
requirements are aimed at ensuring the control protocols are not the 
limiting factor in achieving a particular network’s performance. 
Implementation dependencies are out of scope of this document. 


Other documents may be needed to define how GMPLS protocols meet the 
requirements laid out in this document. Such future documents may 
define extensions or simply clarify how existing mechanisms may be 
used to address the key requirements of highly dynamic networks. 


2. Background 


The Defense Advanced Research Projects Agency (DARPA) Core Optical 
Networks (CORONET) program [Chiu] is an example target environment 
that includes IP and optical commercial and government networks, with 
a focus on highly dynamic and resilient multi-terabit core networks. 
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It anticipates the need for rapid (sub-second) setup and SONET/SDH- 
like restoration times for high-churn (up to tens of requests per 
second network wide and holding times as short as one second) on- 
demand wavelength, sub-wavelength, and packet services for a variety 
of applications (e.g., grid computing, cloud computing, data 
visualization, fast data transfer, etc.). This must be done while 
meeting stringent call-blocking requirements and while minimizing the 
use of resources such as time slots, switch ports, wavelength 
conversion, etc. 


3. Motivation 


The motivation for this document, and envisioned related future 
documents, is two-fold: 


1. The anticipated need for rapid setup, while maintaining low 
blocking, of large bandwidth and highly churned on-demand 
connections (in the form of sub-wavelengths, e.g., OTN ODUx, and 
wavelengths, e.g., OTN OCh) for a variety of applications 
including grid computing, cloud computing, data visualization, 
and intra- and inter-datacenter communications. 


2. The ability to set up circuit-like LSPs for large bandwidth flows 
with low setup delays provides an alternative to packet-—based 
solutions implemented over static circuits that may require tying 
up more expensive and power-consuming resources (e.g., router 
ports). Reducing the LSP setup delay will reduce the minimum 
bandwidth threshold at which a GMPLS circuit approach is 
preferred over a layer 3 (e.g., IP) approach. Dynamic circuit 
and virtual circuit switching intrinsically provide guaranteed 
bandwidth, guaranteed low-latency and jitter, and faster 
restoration, all of which are very hard to provide in packet-only 
networks. Again, a key element in achieving these benefits is 
enabling the fastest possible circuit setup times. 


Future applications are expected to require setup times that are as 
fast as 100 ms in highly dynamic, national-scale network environments 
while meeting stringent blocking requirements and minimizing the use 
of resources such as switch ports, wavelength converters/ 


regenerators, and other network design parameters. Of course, the 
benefits of low setup delay diminish for connections with long 
holding times. For some specific applications, a trade-off may be 


required, as the need for rapid setup may be more important than 
their requirements for other features currently provided in GMPLS 
(e.g., robustness against setup errors). 
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With the advent of data centers, cloud computing, video, gaming, 
mobile and other broadband applications, it is anticipated that 
connection request rates may increase, even for connections with 
longer holding times, either during limited time periods (such as 
during the restoration from a data center failure) or over the longer 
term, to the point where the current GMPLS procedures of path 
computation/selection and resource allocation may not be timely, thus 
leading to increased blocking or increased resource cost. Thus, 
extensions of GMPLS signaling and routing protocols (e.g., OSPF-TE) 
may also be needed to address heavy churn of connection requests 
(i.e., high-connection-request arrival rate) in networks with high- 
traffic loads, even for connections with relatively longer holding 
times. 


4. Driving Applications and Their Requirements 


There are several emerging applications that fall under the problem 
space addressed here in several service areas such as provided by 
telecommunication carriers, government networks, enterprise networks, 
content providers, and cloud providers. Such applications include 
research and education networks / grid computing, and cloud 
computing. Detailing and standardizing protocols to address these 
applications will expedite the transition to commercial deployment. 


In the target environment, there are multiple Bandwidth-on-Demand 
service requests per second, such as might arise as cloud services 
proliferate. It includes dynamic services with connection setup 
requirements that range from seconds to milliseconds. The aggregate 
traffic demand, which is composed of both packet (IP) and circuit 
(wavelength and sub-wavelength) services, represents a five to 
twenty-fold increase over today’s traffic levels for the largest of 
any individual carrier. Thus, the aggressive requirements must be 
met with solutions that are scalable, cost effective, and power 
efficient, while providing the desired quality of service (QoS). 


4.1. Key Application Requirements 


There are two key performance-scaling requirements in the target 
environment that are the main drivers behind this document: 


1. Connection request rates ranging from a few requests per second 
for high-capacity (e.g., 40 Gb/s, 100 Gb/s) wavelength-based LSPs 
to around 100 requests per second for sub-wavelength LSPs (e.g., 
OTN ODUO, ODU1, and ODU2). 


2. Connection setup delay of around 100 ms across a national or 


regional network. To meet this target, assuming pipelined cross- 
connection and worst-case propagation delay and hop count, it is 


Malis, et al. Informational [Page 5] 


RFC 7709 Very Fast Setup of GMPLS LSPs November 2015 


estimated that the maximum processing delay per hop is around 700 
microseconds [Lehmen]. Optimal path selection and resource 
allocation may require somewhat longer processing (up to 5 
milliseconds) in either the destination or source nodes and 
possibly tighter processing delays (around 500 microseconds) in 
intermediate nodes. 


The model for a national network is that of the continental US with 
up to 100 nodes and LSPs with distances up to ~3000 km and up to 15 
hops. 


A connection setup delay is defined here as the time between the 
arrival of a connection request at an ingress edge switch -- or more 
generally a Label Switch Router (LSR) -- and the time at which 
information can start flowing from that ingress switch over that 
connection. Note that this definition is more inclusive than the LSP 
setup time defined in [RFC5814] and [RFC6777], which do not include 
PCE path computation delays. 


5. Requirements for Very Fast Setup of GMPLS LSPs 


This section lists the protocol requirements for very fast setup of 
GMPLS LSPs in order to adequately support the service characteristics 
described in the previous sections. These requirements may be the 
basis for future documents, some of which may be simply 
informational, while others may describe specific GMPLS protocol 
extensions. While some of these requirements may have implications 
on implementations, the intent is for the requirements to apply to 
GMPLS protocols and their standardized mechanisms. 


5.1. Protocol and Procedure Requirements 


R1 The portion of the LSP establishment time related to protocol 
processing should scale linearly based on the number of traversed 
nodes. 


R2 End-to-end LSP data path availability should be bounded by the 
worst-case single-node data path establishment time. In other 
words, pipelined cross-connect processing as discussed in 
[RFC6383] should be enabled. 


R3 LSP establishment time shall depend on the number of nodes 
supporting an LSP and link propagation delays and not on any off 
(control) path transactions, e.g., PCC-PCE and PCC-PCC 
communications at the time of connection setup, even when PCE- 
based approaches are used. 


R4 LSP holding times as short as one second must be supported. 
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8. 


8. 


T; 


R5 The protocol aspects of LSP signaling must not preclude LSP 
request rates of tens per second. 


R6 The above requirements should be met even when there are failures 
in connection establishment, i.e., LSPs should be established 
faster than when crank-back is used. 


R7 These requirements are applicable even when an LSP crosses one or 
more administrative domains/boundaries. 


R8 The above are additional requirements and do not replace existing 
requirements, e.g., alarm-free setup and teardown, recovery, or 
inter-domain confidentiality. 


Security Considerations 


Being able to support very fast setup and a high-churn rate of GMPLS 
LSPs is not expected to adversely affect the underlying security 
issues associated with existing GMPLS signaling. If encryption that 
requires key exchange is intended to be used on the signaled LSPs, 
then this requirement needs to be included as a part of the protocol 
design process, as the usual extra round-trip time (RTT) for key 
exchange will have an effect on the setup and churn rate of the GMPLS 
LSPs. It is possible to amortize the costs of key exchange over 
multiple exchanges (if those occur between the same peers) so that 
some exchanges need not cost a full RTT and operate in so-called 
zero-RIT mode. 
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